Internet Data Delivery for Future Space Missions' 


James Rash 

NASA Goddard Space Flight Center 
Greenbelt, MD 20771 
301-286-9 >72 
janies.rashfate : . fc.nasa.gov 

Keith Hogie 

Computer Sciences Corporation 
Lanham, MD 20706 
30 1 -794-2* *99 

keith.hogie@g : fc.nasa.gov 

Abstract — Ongoing work at National Aeronautics and Space 
Administration Goddard Space Flight Center (NASA7GSFC), 
seeks to apply standard Internet applications and protocols to 
meet the technology challenge of future satellite missions. 
Internet protocols and technologies are under study as a 
future means to provide seamless dynamic communication 
among heterogeneous instruments, spacecraft, ground 
stations, constellations of spacecraft, and science 
investigators. 

The primary objective is to design and demonstrate in the 
laboratory the automated end-to-end transport of files in a 
simulated dynamic space environment using off-the-shelf, low- 
cost, commodity-level standard applications and protocols. 
The demonstrated functions and capabilities will become 
increasingly significant in the years to cnme as both earth and 
space science missions fly more sensors and as the need 
increases for more network-oriented mission operations. 
Another element of increasing significance will be the 
increased cost effectiveness of designing, building, 
integrating, and operating instruments and spacecraft that 
will come to the fore as more missions take up the approach of 
using commodity-level standard communications 
technologies. 

This paper describes how an IP-based communication 
architecture can support all existing operations concepts and 
how it will enable some new and complex communication and 
science concepts. The authors identify specific end-to-end data 
flows from the instruments to the control centers and 
scientists, and then describe how each data flow can be 
supported using standard Internet protocols and applications. 
The scenarios include normal data downlink and command 
uplink as well as recovery scenarios for both onboard and 
ground failures. The scenarios are based on an Earth orbiting 
spacecraft with downlink data rates from 300 Kbps to 4 Mbps. 
Included examples are based on designs currently being 
investigated for potential use by the Global Precipitation 
Measurement (GPM) mission. 
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Introduction 

The goal of an Internet data delivery approach is to provide 
the simplest, most cost-effective delivery of science data 
when and where needed. The Operating Missions as Nodes 
on the Internet (OMNI) Project at Goddard Space Flight 
Center (GSFC) has been demonstrating these concepts and 
working with future missions to baseline these approaches. 
This paper describes how Internet technologies can facilitate 
new kinds of space operations and support a vision for 
operations of earth and space science missions. The 
application of Internet technologies in space systems will 
increase mission flexibility. The key issues for future 
National Aeronautics and Space Administration (NASA) 
missions have less to do with protocols and more to do with 
basic communication problems. Higher data rates, radio 
frequency (RF) versus optical, longer distances, and cross- 
link communications are but a few of the issues. 

Over the past 40 years, NASA has gone from developing and 
operating custom solutions to adopting more commercial off- 
the-shelf (COTS) products and industry standard solutions. 
There was a time when NASA drove communication 
technology not only in space, but also on the ground. The 
NASA need to move large volumes of data reliably over 
noisy channels in a time-critical environment was out in 
front of any other organization. Now, with the explosion of 
growth in commercial terrestrial communications, the space 
community has the opportunity to use technologies into 
which the private sector has poured billions of dollars. 
NASA Communications (Nascom) has demonstrated the 
value to NASA in changing to IP on the ground. The 
opportunity now exists for NASA to complete this transition 
in space. 

This paper will briefly describe the methods and protocols 
that NASA previously used to communicate with its 
spacecraft. The discussion then describes newer approaches, 
some of which are being studied under contract for the GSFC 
for the Global Precipitation Measurement (GPM) mission. 
This possible GPM approach uses standard Internet 
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technologies and protocols to support all aspects of data 
communications with the spacecraft. 


NASA/GSFC Legacy Mission Support 
Infrastructurj 

Operations and the necessary infrastructure for early NASA 
spacecraft communications and control was very labor 
intensive, requiring a large support staff to monitor and 
maintain the communications lines between ground stations, 
control centers, and users. In addition to the support staff, 
other factors had to be reflected in each mission’s design, 
often in form of unique application code. The first factor was 
the large ratio of data rates for downlink (telemetry) and 
uplink (commanding). Another factor stemmed from the 
problems typically encountered during the integration and 
test (I&T) phase of the mission. 

The Nascom group provided the suppoi t to develop, manage, 
and operate the NASA communications backbone. The early 
paradigm for mission support also required a dedicated 
(normally either 24x7 or 12x5) operations team to monitor 
the spacecraft’s health and safety an I generate command 
loads to support spacecraft operations and the instrument’s 
science collection activities. 


Nascom Support 

NASA initially used a communications backbone that 
consisted of specially developed hardware and software 
components. This legacy system required constant 
monitoring to support alt of the on-orbit missions. Installing 
new features required extensive development and testing 
efforts. The Nascom group provided the support personnel 
who were responsible to continually manage the lines and 
circuits to ensure that the operations team could 
communicate with the spacecraft on an as-needed basis. 
Using this type of a legacy system from the 1980s, Nascom 
employed a staff of 70 programmers to develop and maintain 
the communications systems. Figure 1 identifies the 
underlying data delivery protocols that Nascom has used 
since the early 1960s as well as the network throughput 
capacity using these protocols during that period. 


NASA Network Backbone Capacity 


(2000) ATM Core Deployment 

OC-12 expandable to OC-48 
(1998) IP Upgrade / Expansion 
lOBaseT, 100BaseT, 
lOOOBaseT, or FDDI 
(1995) SCD and PTP Development 
begin IP Transition 

(1989) 4800 Bit Block TDRSS Format 
(1978) 4800 Bit Block MSS Format 
(1960) TTY Systems/Clock & Data 






-700 
-600 
-500 
-400 
-300 
-200 
- 100 
-0 


1960 1978 1989 1995 l l >98 2000 


D Standards Based Systems 
D Transition Systems 
LI Legacy Systems 


Figure 1 . NASA Data Delivery Protocols - Evolution and Throughput 
Capacity Upgrades 

As can been seen from Figure 1, as Nascom moved to more 
standard protocols the throughput capacity increased. This 
allowed Nascom to support missions with progressively 
higher data rates. 

Flight Operations Team (FOT) 

The FOT provides spacecraft support to ensure the health and 
safety of both the instrument suite and the spacecraft, 
monitoring the spacecraft for anomalies and generating 
command uploads on a daily basis to support the spacecraft 
and science operations. An operations team was often 
required to provide continuous, 24-hour operations for 
spacecraft support. At best, the spacecraft required less than 
full-time support by an operations team for either an 8x5 or 
12x7 effort. 

Earlier NASA missions employed an old style tape recorder 
to store science and housekeeping data. When the spacecraft 
was in contact with a ground station, the recorder was 
commanded to rewind and begin a playback. This was the 
only operational method to downlink data; the reliable 
transfer of this data was accomplished by using various data 
coding and forward error correction (FEC) schemes, such as 
convolutional encoding or Reed-Solomon encoding. These 
methods were normally sufficient to ensure reliable data 
delivery even with a noisy RF link, albeit at the sacrifice of 
some throughput. 

With the advent of the next generation of missions, NASA 
moved to a space-qualified solid-state recorder (SSR), but the 
SSR still emulated the older style tape recorders. The use of 
the on-board SSR was a step forward for the spacecraft; 
however, the FOT was still charged with the complex task of 
data management and playback of the recorder’s storage. 
With either of the previous data storage techniques, there was 
no concept of files; the data was simply stored on-board as a 
stream of data. Whenever a station contact occurred, the 
operations team would request a data downlink based upon 
the on-board computer’s addressing scheme. In addition to 
the overhead associated with this version of NASA’s legacy 
systems, each mission required unique development to use 
the Nascom-standard 4800-bit block communications 
protocol. Once the spacecraft transmitted the data, the 
mission-unique ground-based systems would reassemble the 
data and begin the initial level-zero processing, the purpose 
of which was to verify that all data was received without 
errors; any problems would result in a request to retransmit 
the stored data. 

Another time-consuming role for the FOT was the formatting 
of command loads and ensuring that the commands were 
reliably uplinked to the spacecraft. While supporting legacy 
missions, the FOT employed various methods to ensure 
command uplink occurred correctly. These methods were 
normally predicated upon a form of command operations 
procedures (COP) protocol [1]. Possible variations of this 
protocol (a) allowed commands to be received in sequence 
(normal commanding), (b) allowed commands to bypass the 
sequence checks (bypass commanding), or (c) allowed special 
HW commanding to reset the on-board computer (OBC) to a 
“safehold” or cold-start state. 



Command Uplink and Telemetry downl nk differences 

Under the legacy mission domain, a major concept was that 
the telemetry downlink formats and protocols were different 
from those in the corresponding command uplink, e.g., the 
COP protocols. These different formats and protocols had to 
be tested prior to launch to ensure that the spacecraft had 
been successfully checked out. Under this approach, the 
telemetry downlink was used to provide a return link to 
verify that the commands were received in the correct 
sequence. To correctly design this type of an approach, 
unique application SW was required both on the ground and 
on the spacecraft to ensure that commands were not received 
out of sequence. This unique application code also required 
extra test time to ensure that the code worked as designed. 

Integration and Test (l&T) Phase Support 

During the I&T phase of the mission, unique HW and SW 
were required to completely check the instrument suite and 
the spacecraft. Also, the testing process was repeated 
numerous times between instrument I&T and then final 
spacecraft I&T. Typically, the instruments were all tested 
independently at their distant development facilities, and 
then a whole new test phase was conducted as each 
instrument was mated to the spacecraft. With this “waterfall 
style” approach to I&T, interface problems often are not 
detected and corrected until the end when the cost of fixing 
the problem has increased dramatically. 

NASA/GSFC Nascom T ransition 

As indicated in Fig. 1, Nascom began an evolution towards a 
ground-based IP routing mechanism by developing and 
deploying the small conversion devices (SCD) and 
programmable telemetry processors (PTPs). These devices 
supported the use of IP for the ground transport of data; 
however, at that time there still were no modifications to the 
spacecraft on-board systems or the ground support system. 

After the IP transition (which could be regarded as a 
watershed event), Nascom only required a staff of 5 
programmers to maintain the communications system. 
Additionally, with the switch to an IP ground-based 
communications system, Nascom was able to reduce the 
operations staff by consolidating systems and 
responsibilities. Another benefit of the IP transition was that 
Nascom could now more thoroughly use commodity-level 
standards and COTS HW solutions to transport the data 
received at a ground station. With the IP transition approach, 
Nascom ultimately supported a dramatic increase in the 
overall data throughput rates. However, the basic spacecraft 
and ground systems were still based on the legacy concepts; 
NASA/GSFC had not begun to incorporate the concepts of 
the Internet protocols in a complete end -to-end approach. 

This all changed in the mid-1990s; NASA/GSFC began 
funding concepts and prototyping efforts to explore the use 
of a full IP-based communications protocol for space 
missions. This approach is leveraged against the Open 
Systems Interconnection (OSI) seven- layer reference model 
for data communications as noted in Figure 2. 

The OMNI Project at GSFC provided a focal point not only 
for IP-based prototyping to identify concepts, rationale, and 
requirements for the full use of IP for space missions but 


also for testing and evaluating the various IP-based 
approaches and solutions. 



Figure 2. OSI Reference Model for space missions 


Potential New Approach for GPM 

In 2002, the OMNI Project began studying data system 
concepts for the GPM mission to identify and document how 
IP could be used in both the space segment and the ground 
segment. The essential objective was to route data from the 
instruments on-board the spacecraft all the way to the end 
users at either the mission operations control center or any 
group of science users. The GPM mission architecture, data 
flows, and concepts are described in greater detail in the draft 
Global Precipitation Measurement (GPM) Spacecraft and 
Instrument Telemetry Data Flow Interfaces and Operations 
Concepts document [2]. A draft spacecraft architectural 
system, as depicted in Fig. 3, was identified to support the 
GPM mission. This architectural concept employs fault- 
tolerant concepts with dual Ethernet Local Area Networks 
(LANs), dual on-board computers (OBCs), and dual up/down 
cards that also perform more routing functions. 

A major shift for the GPM mission is to replace the storage 
concept, since the GPM spacecraft will be designed with a 
modem operating system that supports file management. The 
GPM spacecraft will store the science data as files rather than 
storing the data as a stream onto a SSR. 

Another conceptual change under review is the data transport 
mechanisms used to support the spacecraft data transfer (both 
uplink and downlink of data). A fully redundant Ethernet 
LAN is being considered to support data transfer between the 
science instruments, the on-board computers (OBCs), and the 
up/down cards using UDP/IP packets to transport the data. 
However, a MIL-STD 1553 data bus is used as the data 
transport mechanism among other spacecraft subsystems 
using the current data packet concepts (e.g., between the 
attitude control subsystem and the OBC). With the insertion 
of the IP suite, any previous unique application code to 
support data transport could be removed since the data 
transport layer is inherent within IP. 

Additionally, the OMNI Project suggested the use of HDLC 
framing for the link layer for the space-ground RF 
transmissions. The proposed use of HDLC is not considered 




risky, because HDLC is the dominant link layer standard in On-board science data transport concepts 

terrestrial networks. Further, currently there are eighty Jhe sdence instrum ents format their data into UDP/IP 

spacecraft that currently employ this link layer framing kets for tr ort t0 the 0 BC via the Ethernet LAN; the 
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of HDLC as a link framing technique on noisy space links; 
including a study completed by ITT Industries on the use of 
HDLC framing compared to CCSDS framing. 2 These studies 
and results can be found on the OMNI web site . 

The OMNI Project also proposed that the GPM mission use 
a standard router at the ground station with the corresponding 
IP mobility and security protocols enabled. These 
capabilities would assist the GPM mission to pass a 
NASA/GSFC security audit and would support the ability to 
more ffeely automate the commanding functions when an 
uplink pathway is needed to command t he spacecraft. 

The data transfer mechanisms were further refined with the 
following application controls: 

On-board science data transport using UDP/IP packets 

Data downlink, including the real-time spacecraft 
housekeeping data (in UDP/IP packets) and science 
data file transfer using the multicast dissemination 
protocol (MDP) application [3], 

- TCP/IP for reliable real-time commanding and 
ack/nack confirmations 

UPD/IP for commanding in the blind 


real-time housekeeping data are sent to the OBC via the 
MIL-STD 1553 bus. In the OBC, the science data are 
removed from the UDP packets and stored into files. These 
files normally contain one minute’s worth of science data; 
but the OBC can be commanded to use different time slices 
to handle different situations, like a TDRSS handover. The 
OBC contains a storage management (SM) task, which 
provides file management for the spacecraft. It opens new 
files, adds the data from real-time UDP packets into the files 
and then closes the files when the maximum time limit, 
usually one minute, is reached. The SM task then moves the 
file into the “hot directory” for MDP to begin the associated 
processing to downlink the file. In this example, MDP acts 
as the initiator of the file transfer to the ground. 

Data downlink from spacecraft to ground station 

The data downlink consists of both real-time housekeeping 
data in UDP/IP packets and the science data files downlinked 
using an MDP server task on the spacecraft. 

These application data, both real-time and science data are 
inserted into UDP/IP packets with the appropriate header 
formats, including the Ethernet, IP, and UDP headers. The 
data are transferred to the up/down card/router. The up/down 
card throttles the data to the I and Q channels at an average 
rate of 150 kbps. When required, the mission operations 






center (MOC) can schedule an S-band single access (SSA) 
pass to provide an increase to the downlink rate and provide 
the capability of downlinking a large volume of data in a 
short period of time. The MOC would schedule an SSA pass 
in the event that there is a backlog of science data on-board 
the spacecraft occurring from a long TDRSS outage (over 
thirty minutes in duration). Shorter o utages resulting from 
TDRSS handovers, or DSN zones of exclusion, will be 
handled by the excess bandwidth within the multiple access 
(MA) link. 

The router or up/down card extracts the application data from 
the Ethernet header and checks the UPD/IP header fields and 
determines that the data are external to the local network. The 
up/down card is responsible for adding the link layer 
header/trailer artifacts. The data are inserted into a new packet 
using an HDLC header frame and “bit stuffed” to mask any 
application data patterns that could match the HDLC one- 
byte flag pattern; this bit stuffing ensures that the HDLC flag 
byte can be used as a frame delimiter. An OMNI Project 
study using three current NASA missions (WIND, POLAR, 
and SOHO) concluded that the bit-stuff ng overhead averaged 
approximately 1% for the set of sample science data. 
Additional details are presented in the OMNI paper [4] 
HDLC Link Framing for Future Space Missions. 

The data are converted into a serial stream for transmission 
by the antenna to the ground site. At the ground station 
antenna, the data are received as a serial stream and 
transferred to a local router. The router strips and processes 
the HDLC frame header/trailer fields ( e.g., the frame sync 
and the CRC information), checks the UDP/IP header 
information to determine the next destination for the data and 
begins the routing process for an eventual transmission of the 
data to that address. On the ground, the standard protocols 
are used to route the spacecraft’s housekeeping data to the 
control center or any other desired location. On the ground, 
the routers continually monitor the data quality by checking 
the HDLC/Ethemet CRC information as well as the IP 
checksum and UDP checksum fields. The checks using these 
fields ensure that only “good quality” data are transmitted; 
no “bad quality” data would be transmil ted to the end-user. 

The GPM spacecraft may use the Multicast Dissemination 
Protocol (MDP) applications task, which guarantees reliable 
data file delivery over a variety of link types, either 
infrequent return links or full duplex links. 

MDP is a reliable file transfer application built upon UDP 
and is one of many current applications used to support a 
reliable multicast transport (RMT) protocol. The Internet 
Engineering Task Force (IETF) has chartered a working 
group, the RMT WG, to standardize reliable multicast 
transport protocols for “one-to-many bulk data” transport. 
This working group is currently defining three protocol 
instantiations, which can be used to support a reliable 
multicast: 

NORM, the Nack Oriented Reliable Multicast 
protocol, which uses NACKS fc r reliability 

- TRACK, TRee ACKnowledgment based protocol, 
which uses a tree for controlling feedback and repairs 

ALC, Asynchronous Layered Coding, which uses 
FEC based techniques and does not require any 
feedback 


The OMNI group is currently using the MDP based approach 
for a reliable file transfer to support a space to ground transfer 
of the on-board files. However, the OMNI group is working 
with the RMT and will use one of the three defined 
approaches listed above, whenever they become standardized 
within the working group. Additional details on the roles, 
responsibilities, and charters of the reliable multicast 
transport working group are contained on the IETF web site 

With MDP, minimal, or no, operator intervention is required 
to downlink stored files. The OBC contains a storage 
management (SM) task, which acts as the initiator of the data 
transfer when a file is complete with its allotted science data. 
The SM task will put the science data file into the MDP’s 
“hot directory”, which triggers MDP to begin processing this 
file for downlink to the ground station. The MDP 
application will segment the science files into one Kbyte 
packets; MDP sends these 1 -Kbyte packets to spacecraft’s 
up/down card where the identical processing as discussed in 
the previous sub-section is done. 

Once on the ground, the data are routed using the original 
destination information, as sent from the spacecraft. The 
real-time spacecraft data are forwarded to the MOC and used 
to monitor and trend the health and safety of the spacecraft 
and instruments. At the ground station, a variety of options 
are available to disseminate the science data, including file 
storing and forwarding, forwarding data as UDP packets to 
one central location, or multicasting these UDP science 
packets to many users, or any combination of these options. 

File Store and Forward 

As one of the scenarios, the data initially could be transferred 
to a client MDP task on the ground station. This MDP client 
task reassembles the 1 -Kbyte packets into a copy of the 
original file and maintains the responsibility for ensuring 
data completeness by transmitting the necessary 
acknowledgments or negative acknowledgments. This MDP 
client task provides a post-processing option that enables this 
file to be transferred to any required user or group of users. 

Real-time UDP packet transfer 

As an alternative example, the real-time science data initially 
bypass the MDP client and are automatically routed to all 
science users who need the data for real-time displays. The 
data also are routed to the MOC (or any other central 
location) where an MDP client task reassembles the 1 -Kbyte 
packets into the copy of the original file. This MDP client 
task performs the necessary acknowledgments or negative 
acknowledgments to ensure data completeness. 

These data routing alternatives are examples of the ways in 
which the mission engineering trade space is opened up 
through the use of standard networking technologies and 
protocols. 

Real-time TCP/IP commanding 

Under the proposed approach, the spacecraft becomes a 
mobile node on a network and becomes attached to that 
network successively at different locations, i.e., the different 
ground stations. Advanced groups in private industry are 
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currently addressing a similar issue ir relation to wireless 
networking for cars, laptops, personal digital assistants 
(PDAs), and a multitude of other electronic devices that will 
be mobile and require IP network access. The IETF is 
currently working to establish the standards, practices and 
applications for wireless networking for mobile nodes. 

GPM is considering the proposed use of standard mobile IP 
protocols to support the forward link required for a TCP/IP 
connection for real-time command delivery. The router 
located at the station will have both mobile IP and IP 
security protocols enabled to support the GPM mission. The 
router will act as the foreign agent and advertise its 
availability; this agent advertisement will be scheduled to 
occur several seconds before the actual time that the forward 
link is scheduled to begin. The spacecraft will respond to 
this advertisement and return authorization packets, which are 
routed to the MOC for authentication. Within a matter of 
seconds and with a minimum of 2-3 packets, the spacecraft 
and the MOC have established a tunnel by which data from 
the MOC can be uplinked to the spacec raft. This uplink data 
consists of command data, the MDP ACK list and the MDP 
NACK list. The command data are used to continue 
spacecraft and instrument operations and to maintain the 
health and safety of the mission. The NACK list is used to 
request retransmission of missing data while the ACK list is 
used to confirm the successful receipt of the data file at the 
MOC. 

UDP/IP for commanding in the blind 

The non-reliable data transport for command data is 
accomplished using a connectionless 1IDP session. This is 
similar in concept to what is done to support current mission 
with CCSDS blind commanding. In this scenario, no mobile 
IP routing is established since by definition, mobile IP 
implies a two-way connection. For blind commanding, it is 
necessary to establish a forward link to the spacecraft to 
uplink some type of data (commands). 

Instead of mobile IP and the agent advertisement that would 
be performed by the ground station routers, the MOC 
manually establishes a tunnel to a specific ground station 
router; this would be analogous with the approach that the 
MOC’s currently use to establish a session with a specific 
station/antenna as part of the pre-pass setups. The process can 
be automated to occur several minutes before a station 
contact, or, in the event of a critical spacecraft problem, the 
FOT can command it to occur when a station can 
communicate with the spacecraft. Once the tunnel is 
established between the MOC and the ground station, the 
command data are transmitted to the station in UDP packets, 
not a TCP byte stream as was done in the previous scenario. 

Fail-over and recovery scenarios 

GPM has considered the use of backup ground stations to 
support the mission in the event of a failure of the GPM- 
TDRSS communications link. In the event of this 
contingency situation, the data deliver/ requirements will be 
relaxed because of the somewhat infrequent station contacts. 
To fully support this scenario, the ground site(s) would only 
need to have a standard router that can support both IP 
security and IP mobility protocols. However, in this failure 
scenario, the real-time data would not always be flowing to 
all science users. The MOC would still be capable of 


providing the files for the complete set of science products. 
In the event of this failure scenario, a ground station would 
have approximately 4- to 8 -minutes of spacecraft contact, 
with an average of approximately 7-minutes. During the 
contact, the MOC would command the spacecraft to 
downlink the data at a rate up to 4 Mbps, depending upon 
the station supporting the ground contact. The downlink rate 
needs to be sufficient to allow transmission of all science and 
housekeeping files and real-time spacecraft data and to ensure 
that NACKs/ACKs can be sent to the spacecraft before the 
end of the contact. Whatever data are not successfully 
transmitted during the contact will be resent at the next 
available station contact. 

In this scenario, the GPM instruments continue to create the 
science data and the OBC will create the files corresponding 
to the data and put these files into the “hot directory”. These 
files will reside on-board the spacecraft until the spacecraft 
establishes a downlink with the MOC. When the spacecraft 
has a downlink established, the MDP server automatically 
begins transmitting the files at the commanded downlink 
rate. 

Future Efforts 

Complete security studies 

Before any new mission is allowed access to the GSFC 
closed IP Operational Network (IONet); the project must first 
complete a Risk Assessment document that identifies the 
possible risks associated with adding this control center to 
the network, as well as the mitigation efforts to ensure data 
integrity and facility security. In addition to this standard 
risk assessment document, any mission using a full-up IP 
implementation would be required to complete an IP-in- 
Space Risk Assessment, as required by the NASA/GSFC IT 
security organization. The OMNI Project is actively working 
with the IT security organization and several of the security 
studies are currently under way. 

Each new mission at NASA that plans to use an IP-in-Space 
architecture approach will be required to complete a 
corresponding risk assessment security study and document 
their risks and mitigation activities. The mission would 
submit these studies and documents to the NASA/GSFC IT 
security organization for ratification and acceptance. 

Prototyping issues 

The OMNI Project is tasked to complete several trade studies 
and prototyping efforts over the next year to provide 
additional input on how GPM could be designed to use the 
full IP implementation approach. 

The OMNI Project has another effort underway to support a 
flight-based MDP system, which is scheduled to be tested in 
the summer of 2002 on the Communication and Navigation 
Demonstration on Shuttle (CANDOS) mission. This 
mission is part of a 16-day Shuttle flight, and has its own 
independent transceiver, which will be used to directly 
contact either ground stations or TDRSS, independent of the 
Shuttle communications system. CANDOS will demonstrate 
basic IP connectivity on the space link, mobile-IP routing, 
and reliable file transfer using MDP. The CANDOS mission 
is discussed in more detail in the paper “Space 


Communications Demonstration Using Internet 
Technology”[5]. 

Another prototyping effort, by a separate group that develops 
flight hardware, is in the planning phase to develop a space 
qualified onboard LAN, including the up/down card/router; 
OMNI currently has scheduled this activity to be completed 
later this year. 

Conclusions 

As previously described in this paper, the full use of an IP 
implementation for a space mission can be done with 
minimum risk. A full end-to-end IP approach provides 
simple and flexible communications that manages all 
mission requirements. 

Technically, IP works fine in space; there are no 
showstoppers. The only remaining concern is simply the 
application of a standard engineering process with the 
engineering solution space enlarged. 

Organizationally, IP can enable a new way of doing business. 
IP enables advanced mission concepis (e.g., collaborative 
science) and allows better alignment with industry standards 
and products. IP supports a simpler, yet more capable, 
overall mission design and enables \ simpler operations 
solution. 

The OMNI Project has successfully completed prototyping 
and demonstration activities using a total end-to-end IP- 
based architecture. The OMNI Black Sea mission to test the 
prototype IP mission during a solar eclipse took place in 
1999 [6], followed by the UoSat-12 mission [7], and the 
laboratory OMNI Flatsat development [8]. The OMNI 
Project is currently supporting the CANDOS mission. These 
approaches and results are documented on the OMNI website 
[j. The OMNI Project has shown that a complete IP system 
not only can be done but also has been done. The next 
generation solutions are on the drawing board. The vision 
will include a full end-to-end IP solution that will evolve to 
support advanced mission concepts and profiles as depicted 
in Fig. 4, with levels of interoperability for future missions 
that have not been available in a cost-effective manner up to 
this time. 



Fig A. Evolutionary Vision of IP fo r M ssion Applications 

4 http: ipin space. tisfc.nnsa.npv/ 


This approach will make it easier for a constellation of 
satellites to directly communicate with one another, 
transferring data directly between the spacecraft rather than 
downlinking data, processing it on the ground and then 
uplinking the data. The use of commodity-level standard 
transport and routing protocols will reduce development 
costs, shorten schedules, and allow for earlier integration and 
test activities, thereby maximizing science return per dollar 
invested. 
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